home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000520_dsr@hplb.hpl.hp.com _Fri Jan 8 14:32:15 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  9KB
  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA28917; Fri, 8 Jan 93 14:32:15 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA13340; Fri, 8 Jan 1993 14:47:10 +0100
  6. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 8 Jan 93 13:44:04 GMT
  7. Received: by manuel.hpl.hp.com
  8.     (16.6/15.6+ISC) id AA09490; Fri, 8 Jan 93 13:48:21 GMT
  9. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  10. Message-Id: <9301081348.AA09490@manuel.hpl.hp.com>
  11. Subject: Customer pull on HTTP2
  12. To: www-talk@nxoc01.cern.ch
  13. Date: Fri, 8 Jan 93 13:48:18 GMT
  14. Cc: dsr@hplb.hpl.hp.com
  15. Mailer: Elm [revision: 66.25]
  16.  
  17. I am getting really excited about the possibilities for the Web for a variety
  18. of roles. Much us this however depends on getting the right features into
  19. HTTP2. I would very much like comments on the following suggestions.
  20.  
  21. Authentication
  22. --------------
  23.  
  24. I think that every HTTP2 request (not just GET) should include the "From"
  25. field, and that it is strongly desirable to include the user's full name,
  26. e.g.
  27.  
  28.     From: dsr@hplb.hpl.hp.com (David Raggett)
  29.  
  30. The user's name must be easy to extract regardless of the particular variant
  31. of email addressing scheme.
  32.  
  33. For some services the server may need to check if the user is authorised for
  34. this service. In many cases the Internet (numeric) address and the information
  35. in the "From:" field will suffice.
  36.  
  37. Additional security will require a password. I think this should be a header
  38. in its own right. The "POST" command names a document that you wish to post a
  39. response to. That document may not be owned by you so it doesn't seem right to
  40. muddle up the authorisation for the POST command with that documents Udi.
  41.  
  42. so lets have a new header  "Password:  xyzzy"
  43.  
  44. A further trick would be to encrypt your password for this server/service
  45. together with the time of day using a scheme agreed by you and the server. The
  46. server then decrypts the value sent with the Password header to extract the
  47. password, and time of day and checks that the time is correct  to within a
  48. margin for network delays.
  49.  
  50. This only effects the HTTP2 protocol in requiring different error codes to
  51. distinguish the cases:
  52.  
  53.     a)  your Internet address is not permissible for this service
  54.     b)  your user name is not permissible for this service
  55.     c)  your password is incorrect
  56.     d)  your password is ok, but the time check failed
  57.  
  58.  
  59. Basic need for administrators identify and even to mail users.
  60. Frequent need for authentication - not just on GET
  61. encrypt password + time of day to foil copying password
  62.  
  63. Needless to say the value for the Password header should be composed of
  64. printable 7 bit ascii characters, excluding white space and control chars.
  65.  
  66.  
  67. Caching
  68. -------
  69.  
  70. It will be desirable to avoid overloading servers with popular documents by
  71. supporting a caching scheme at local servers (or even at browsers?). This
  72. implies that document headers should provide sufficient information to make
  73. this practical.
  74.  
  75. Servers need to be able to work out what documents to trash from their caches.
  76. A simple approach is to compare the date the document was received with the
  77. date it was originally created or last modified. Say it works out that when
  78. you got the document it was already one week old. Then one rough rule of thumb
  79. is to trash it after another week. You can be rather smarter if there is a
  80. valid expiry date included with the document:
  81.  
  82.     o   the document header should *always* include a "Date:" field giving
  83.         the date it was last written to
  84.  
  85.     o   the "Expires:" field is optional
  86.  
  87.     o   the date values should be in a prescribed format to simplify
  88.         machine interpretation (Is this adequately defined by existing RFCs?)
  89.  
  90. I think that we need to provide an operation in which the server returns a
  91. document only if it is later that a date/time supplied with  the request. If
  92. it is the same (or earlier) the server should return a suitable status code
  93. and an optional "Cost:" header, see below.
  94.  
  95. This is already provided for:
  96.  
  97.     GET udi
  98.     SINCE datatime
  99.  
  100. The meaning of SINCE needs to change as in Tim's original description of HTTP
  101. it means "greater than or equals", whereas I want strictly "greater than".
  102.  
  103. Note that servers shouln't cache documents with restricted readership since
  104. each server don't know the restrictions to apply. This requires a further
  105. header to identify such documents as being unsuitable for general caching:
  106.  
  107.     Distribution: restricted | unrestricted
  108.  
  109. This header is only needed for documents with restricted readership.
  110. An dirty alternative would be to set the expiry date to the same value as
  111. supplied with the "Date:" header.
  112.  
  113. Copyright & Payments
  114. --------------------
  115.  
  116. Although the Internet backbone restricts profit making services, many subnets,
  117. such as University campuses, and company subnets such as HP's have no such
  118. problem. Indeed users strongly want access to copyrighted information for
  119. which a payment is due.
  120.  
  121. My suggestion is that servers are responsible for tracking who accesses what
  122. information, and hence how much they owe. For use within Hewlett Packard for
  123. library services, we anticipate including some extra headers in the request:
  124.  
  125.     EmployeeNumber: 148689
  126.     LocationCode:   8126        (an account number for cross charging)
  127.  
  128. This would be stripped off when sending requests to servers outside the HP
  129. subnet. These headers are ignored by servers which conform to strict HTPP2.
  130.  
  131. I would like the document header to include an optional cost header, e.g.
  132.  
  133.     Cost: 4.05 US DOLLARS
  134.     Copyright: Reuters Inc.
  135.  
  136. This would let the users know how much a given document has cost them, as well
  137. as who owns the copyright. The latter heading is needed since you can't always
  138. put it in the document, e.g. think of photographic images.
  139.  
  140.  
  141. The "Cost: 4.03 US DOLLARS" field
  142.  
  143.  
  144. Copyright and Caching
  145. ---------------------
  146.  
  147. What happens if a copyright protected document is saved in the cache of a
  148. local server? We have got to ensure that the rightful owners get paid for
  149. access even when the document is obtained from a local server's cache.
  150.  
  151. My idea is that for each access, this server should inform the server on which
  152. the original document resides. This notification can however be deferred to
  153. a time when the network is quiet ...
  154.  
  155. The notification proceeds using the "GOT" command
  156.  
  157.     GOT udi
  158.     From: dsr@hplb.hpl.hp.com (David Raggett)
  159.     Server: hplose.hpl.hp.com
  160.     EmployeeNumber: 148689          /* HP specific */
  161.     LocationCode:   8126            /* HP specific */
  162.  
  163. The From header gives the name of the user who requested the document. The
  164. Server header names the machine with the cache, and other company specific
  165. fields are used for accounting purposes.
  166.  
  167. Note that this scheme can't be used for documents with restricted readership,
  168. since the server looking after the cache doesn't know who is and who isn't
  169. allowed to read this document.
  170.  
  171. The protocol ought to allow for multiple GOT statements (and associated
  172. headers in the same message. For this it seems simple enough to require a
  173. terminating blank line.
  174.  
  175.  
  176. Naming Parts of a Multipart body
  177. --------------------------------
  178.  
  179. It would be nice to use the MIME format's capability to send multiple
  180. documents as part of the same message, e.g. an HTML doc with several
  181. pictures. To make this work each separate part needs to include the
  182. Document Udi in its header, so that the browser can check if it has the
  183. document in its local cache (history stack) or whether it needs to make
  184. network request for the picture etc.
  185.  
  186.     DocumentName: Udi
  187.  
  188.  
  189. Effective support for discussion groups
  190. ---------------------------------------
  191.  
  192. My model is that discussion groups each have unique Udi's. Each discussion
  193. group has a sequence of base notes, and each base note is associated with a
  194. sequence of responses. I am unsure of how to deal with cross postings!
  195.  
  196. Over a period of time the number of base notes can grow arbitrarily, and we
  197. need a way of listing all those within a given time period. This can be
  198. supported using Tim's BEFORE and SINCE modifiers in association with the GET
  199. command. The server is responsible for creating an HTML document corresponding
  200. to the list of base notes (and how many responses there are for each etc.).
  201.  
  202. In retrieving a base note, you should get an indication of how many responses
  203. there are using the header:
  204.  
  205.     Responses:  16
  206.  
  207. You also need a way of retrieving a given response. One way is to ask for the
  208. list of Udi's for all the responses, another is a command to get a particular
  209. response given the Udi for the base note and a sequence number, e.g.
  210.  
  211.     RESPONSES Udi           /* request the list of response's as an html doc */
  212.     GETRESPONSE 12 Udi      /* get a given response (12th in the list) */
  213.  
  214.  
  215. What do people think?
  216.  
  217.  
  218. I assume the POST command can be accompanied by an html doc as a body.
  219.  
  220. Looking forward to your comments,
  221.  
  222. David Raggett